This chapter discusses advanced tools that you can use to administer the SpinServer. The tools in this section require that you access the SpinServer with a Linux shell. The tools discussed here are not accessible via the SpinManager CLI or GUI. Use these tools only if you are familiar with Linux/UNIX shells.
The following advanced tools are available:
The spinsh command, as discussed in Section 24.1.
The buildexports command, as discussed in Section 24.2.
Pluggable authentication modules (PAM), as discussed in Section 24.3.
The vfsdump and vfsrestore commands, as discussed in Section 24.4.
You can access SpinManager CLI commands in a shell on the SpinServer by using the spinsh command, both interactively and in scripts. The command has the following syntax:
# /bin/spinsh [-e] [h] [-t] [-v] [-y] [-c command]
where
-e specifies that the spinsh command abort if any of the commands issued under it fail. This option is used only in batch mode.
-h displays command usage.
-t displays the execution time, in seconds, of the command after the command is run.
-v displays all fields in show commands.
-y disables any confirmation messages associated with commands that are run under the spinsh command.
-c command specifies a single CLI command to run, after which the spinsh command exits.
The buildexports command is available for advanced management of export rule sets. See Chapter 16 for additional information about managing export rule sets. The command reads one or more export file lists and creates or updates export lists based on the specifications located in the file.
The command has the following syntax:
# /usr/sbin/buildexports [-s server] [-hvV] [-g netgroup_file_name ...] rule_set_file_name...
where
-s server specifies the server on which the command is to run. The default is localhost.
-h displays command usage.
-v specifies verbose output.
-V displays the version of the program.
-g netgroup_file_name specifies the name of a group definition file. The file must be in the standard Solaris netgroup(4) format, which is the same format displayed by the ypcat -k netgroup command. If groups are not included in the rule set file specified by the rule_set_file_name parameter, you do not need to use this option. You can specify multiple -g netgroup_file_name parameters to use multiple netgroup files.
rule_set_file_name specifies the name of a text file that contains export-list descriptions. You can specify multiple arguments to use multiple rule-set files. Blank lines and white space in the file are ignored, and the pound character (#) indicates a comment to the end of the current line. The file must contain lines of the following two forms:
ruleset name # Begins a rule set definition for name
rule host_or_group mask_bits RO_rule RW_rule # Adds a rule
In the rule line, the rule is specified as follows:
host_or_group specifies either a host (as a host name or IP address) or a netgroup prefixed with the at character (@). For instance, the expression @mygroup specifies a group called mygroup. If a netgroup is specified, a netgroup file name must be specified by using the -g parameter.
mask_bits specifies the number of mask bits in the rule. Possible values range from 0 to 32.
RO_rule specifies the read-only rule. Possible values include any, cifs-ntlm, cifs-kerberos, nfs-kerberos, and never. See Section 16.2.6.6 for a description of these values.
RW_rule specifies the read-write rule. Possible values include any, cifs-ntlm, cifs-kerberos, nfs-kerberos, and never. See Section 16.2.6.6 for a description of these values.
The following is an example of a rule-set file:
ruleset englab-only
rule @englab 16 any any # read-write for hosts in @englab
rule 0.0.0.0 0 any never # rest of world read-only
ruleset webserver-config
rule webmaster-pc.it.example.com 32 any nfs-kerberos
# no access for anyone else
When the buildexports command is used to create export rule sets, each rule line in the rule set file or files is expanded into enough actual rules to cover all of the IP addresses that are needed to represent the host (for instance, multihomed hosts by name) or the netgroup (which can include multiple hosts). If a single rule line expands to multiple IP addresses, the mask bits, read-only rule, and read-write rule apply to all of the rules that are created for the expanded set of IP addresses.
The SpinServer uses pluggable authentication modules (PAM) to provide mappings from user and group names to IDs. This enables you to alter the mapping algorithms by providing your own PAM modules. The mappings are used in the following contexts:
Translation of user names to and from the IDs in the SpinManager CLI and GUI for the -usertype, -user, -group, and -domain parameters of the following commands:
filestorage vfs modify
filestorage vfs new
filestorage vfs show
vservers servers modify
vservers servers new
vservers servers show
Translation of user names to and from the IDs for CIFS servers when CIFS-to-NFS mappings are specified. When a CIFS user ID is mapped to an NFS UID, the CIFS ID is passed through the regular-expression mappings; the result of that mapping is looked up in PAM. When an NFS UID is mapped to a CIFS user ID, the NFS UID is looked up in PAM to get a name, and the name is passed through the regular-expression mappings to obtain the CIFS user ID.
Translation of NFS-Kerberos principal names to NFS UIDs. The NFS-Kerberos client principal name is passed through the regular-expression mappings; the result of that mapping is looked up in PAM to get the UID. This is a one-way mapping; the UID is never translated back to an NFS-Kerberos principal name.
Note: PAM does not affect NFS-only service; standard NFS UIDs are not translated or passed through PAM for authentication.
SpinServer PAM modules must be custom written for translating names to IDs. Third-party PAM modules written for other purposes are not sufficient for use on the SpinServer. For more information about the availability for PAM modules or for details about writing your own PAM modules for use on the SpinServer, contact Network Appliance Technical Support. The default PAM module is named spin_file.so; it is configured by setting up NIS domains for a virtual server through the SpinManager interface, and does not require the following steps to enable it.
Important: The following steps must be performed correctly and identically on each SpinServer in a cluster. Performing any of the steps incorrectly results in inconsistent mappings from SpinServer to SpinServer, which can result in problems such as the inability to access data.
To enable PAM on a SpinServer, perform the following steps:
Log onto the SpinServer as root.
Change to the /etc/pam.d directory:
# cd /etc/pam.d
Locate the file named spinauth.default. This file controls the PAM configuration for any virtual server that does not have its own configuration file. To create a PAM configuration file for a single virtual server, copy the spinauth.default file to a file named spinauth.vsN, where N is the ID (not name) of the virtual server whose configuration you want to edit. For instance, the configuration file for a virtual server with the ID 2 is named spinauth.vs2. You can obtain the ID for a virtual server by using the vservers servers show command, as described in Section 12.2.2.
Open the appropriate spinauth file in a text editor.
The second line of the file reads as follows:
auth required /lib/security/spin_nis.so
Edit the line as follows, replacing spin_nis.so with spin_file.so:
auth required /lib/security/spin_file.so
Change to the /var/spinauth directory:
# cd /var/spinauth
By default, this directory is empty.
Create password and group files for the file specified in Step 4. The files must be in the standard UNIX password and group file format. To create the files from NIS, run the following commands:
# LD_PRELOAD=/usr/spinmgmt/lib/bindresvport.so ypcat -d domain_name passwd.byname > passwd_file_name # LDPRELOAD=/usr/spinmgmt/lib/bindresvport.so ypcat -d domain_name group.byname > group_file_name
The password file (passwd_file_name) can be named either passwd.default or passwd.vsN, where N is the virtual server ID; the passwd.default file is used by virtual servers that do not have an associated passwd.vsN file. Similarly, the group file (group_file_name) can be named either group.default or group.vsN; the group.default file is used by virtual servers that do not have an associated group.vsN file.
If needed, edit the password and group files to affect the mappings from names to IDs.
Perform Steps 1 through 7 on all other SpinServers in the cluster. Make sure to perform the steps identically on each machine.
The VFS dump and restoration facilities enable you to write the contents of a VFS to standard output or a specified dump file, and then to restore the contents of the VFS. These facilities can be used for the following purposes:
As part of a custom backup solution
To copy a VFS from one cluster to another (the SpinCopy mechanism enables copies only within the same cluster)
To copy a VFS from one server to another when it is inefficient to use SpinCopy (for instance, if a large VFS needs to be copied to a distant server, and only limited bandwidth is available)
The VFS dump and restoration facilities are provided as a set of application programming interfaces (APIs). The vfsdump and vfsrestore commands, which are programs that implement these APIs, are installed as compiled executable files on the SpinServer. This section describes the commands, not the APIs. For information on the APIs, contact Network Appliance Technical Support.
Note: The VFS dump and restoration interface does not provide for the backup and restoration of a subset of a VFS's files and directories. If you require this functionality, use the SpinServer's NDMP backup and restoration functionality with a third-party utility such as VERITAS NetBackup or Legato NetWorker.
The vfsdump command writes the contents of a VFS to standard output or a specified output file. By default, the command takes a read-only SpinShot of the source VFS and creates a dump from the SpinShot. The command has the following syntax:
# /sbin/vfsdump [-h] [-s spinserver] [-l previous_label] [-n] [-c] [-t timeout_value] [-o [output_file]] VFS_name
where
[-h] displays syntax and usage information for the command.
[-s spinserver] specifies the name or IP address of a SpinServer in the cluster in which the source VFS is located.
[-l previous_level] specifies the label of a previous dump file for an incremental dump.
[-n] specifies that, if the source VFS is a read-write VFS, a SpinShot is not first taken of the source VFS. To ensure consistency, a VFS cannot be modified while a dump of it is created. If you specify this parameter, the SpinServer takes the source VFS offline while the dump is created, then sets the VFS online when the dump is complete.
[-t timeout_value] specifies the connection timeout value, in seconds. The default is 3 seconds.
[-o [output_file]] specifies the name of a file to which dump output is to be directed. By default, dump output goes to STDOUT.
VFS_name specifies the VFS whose contents are to be dumped.
The following example dumps the contents of a VFS named user.eric to a dump file named /tmp/user.eric.dump. The VFS is located in a cluster that includes a SpinServer named Server1. This is a full dump, not an incremental dump.
# vfsdump -s Server1 -o /tmp/user.eric.dump user.eric
The vfsrestore command restores the contents of a VFS from a VFS dump. Data can be restored either to a new VFS or to an existing VFS. The command has the following syntax:
# /sbin/vfsrestore [-h] [-s spinserver] [-i input_file] [-f] [-t timeout_value] [-p storage_pool_name] [-v virtual_server_name] VFS_name
where
[-h] displays syntax and usage information for the command.
[-s spinserver] specifies the name or IP address of the SpinServer on which the restored VFS is to be located.
[-i input_file] specifies the name of a file from which dump data is to be restored. By default, input is read from STDIN.
[-f] specifies that data is to be forcibly restored if the specified dump file is out of sequence.
[-t timeout_value] specifies the connection timeout value, in seconds. The default is 3 seconds.
[-p storage_pool_name] specifies the name of the storage pool on which the restored VFS is to be created. Specify this parameter and the -v parameter only if a new VFS needs to be created to hold the restored data.
[-v virtual_server_name] specifies the virtual server on which the restored VFS is to be created. Specify this parameter and the -p parameter only if a new VFS needs to be created to hold the restored data.
VFS_name specifies the name of the VFS to which dump data is to be restored. If the VFS does not already exist, the command creates the VFS.
Important: An aborted VFS restoration can leave the target VFS in an inconsistent state. If a restoration is aborted, restart the restoration process with the first full dump of the source VFS. After a restoration failure, the damaged VFS is marked as offline and cannot be brought online until it is checked by spiff, the SpinFS file-system checking tool. Contact Network Appliance Technical Support for assistance with running spiff.
The following example restores the contents of a dump file named /tmp/user.eric.dump:0:1054295 to a VFS named user.eric.new on a SpinServer named Server2. The new VFS is created on a storage pool named pool2 and a virtual server named vs0.
# vfsrestore -s Server2 -i /tmp/user.eric.dump:0:1054295 -p pool2 -v vs0 user.eric.new
A dump file can be either a full dump, consisting of all data in a VFS, or an incremental dump, consisting of data that has changed since a previous dump. Each dump file has a unique label in the following format:
dump_file:lowest_data_version:highest_data_version
where
dump_name is the name of the dump file as specified by the client. This name is typically but not necessarily the name of the VFS whose data is being dumped.
lowest_data_version is the data version of the oldest modification included in the dump.
highest_data_version is the data version of the most recent modification included in the dump.
The following example is the label for a dump of a VFS named home.root, whose oldest modification is data version 93571 and whose most recent modification is data version 143209:
home.root:93571:143209
The maximum length of the label is 200 characters. If the length of a label exceeds 200 characters, the dump_name portion of the label is truncated as needed.
Copyright © 2004 Network Appliance, Inc.; copyright © 2003, 2004 Spinnaker Networks, LLC. All rights reserved. Specifications subject to change without notice.